1. Field of Invention
The present invention relates generally to software design patterns used in object oriented and procedural languages; More particularly, the present invention describes a method of building software components and systems using a new design pattern that reduces and simplifies the steps required to configure and dynamically control a software function in a multi-threaded environment, both at program implementation time and during software execution, and also to simplify monitoring by external processes of function's internal state, during runtime.
2. Background
Design patterns are recognized ways of repeatedly designing software to achieve predictable, and simplified designs. In software and other abstract reproductions of real world processes, there exists a desire to discover, design and use new design patterns which simplify designs by emulating real world Tools and processes. Such design patterns are ideally easy to learn & read, while also not sacrificing flexibility of the control-ability or monitor-ability of the process, both before and during execution. To achieve these goals, a software design pattern must very closely mimic distinct, real world processes and Tool designs.
However, current software design-patterns and prior art have thus far not described or implemented a single and consistent design pattern that is comprised of at least 4 distinct yet essential components: the subject to be acted upon (operand) or created, a Tool (function) to perform that action, a Configuration Instrument which can predefine the Tool's behavior before runtime, a Control Instrument which can control the Tool's behavior before and during runtime, and finally, a State Instrument that the Tool can use to allow external processes to monitor its internal states (such as for process regulation or human interface status reporting)
Current object-oriented design patterns for object factory or object mutating purposes typically require that a program writer must, in discrete steps: first call an object factory method or otherwise instantiate some Tool object, then call one or more of that single object's functions in some order to configure the Tool object, and finally call another function one or more times to start the function's execution phase, to create or modify an existing object. The order that these steps should be performed may cause confusion and so may yield an inconsistent behavior among Tools of related types. Additionally, the functions may have argument lists which are large and have input orders which further add a level of complexity and labor that must be performed by the programmer. Finally, the objects do not have methods which clearly isolate the control and state monitoring capabilities that real world Tools posses.